三大服务网格是Istio、Linkerd和Consul。它们使用管理集群级数据流量的“控制平面”和“数据平面”，直接面对在网格内的服务之间处理数据的功能。

调试 Istio

您可以使用以下两个命令之一深入了解Istio网格中的流量：

istioctl proxy-status

istioctl proxy-config

您还可以浏览调试日志。注意，debug是Istio日志的五种可能输出之一（其他是none、error、warn和info）。注意，调试将提供最多的数据，一些开发者认为Istio在日志方面信息量很大。

以下示例定义了要分析的不同范围：

istioctl analyze --log_output_level

klog:debug,installer:debug,validation:debug,validationController:debug

左右滑动查看完整代码

调试Linkerd

调试的默认方法是使用调试容器（调试边车）。然而，Linkerd调试的工作方式因您使用的应用程序类型而异。

比如说，您将使用度量指标来调试HTTP应用程序和gRPC应用程序的请求跟踪。

调试502s，即错误的网关响应

调试控制平面端点

使用度量指标调试HTTP应用程序

使用请求跟踪调试gRPC应用程序

调试502s，即错误的网关响应

调试控制平面端点

使用度量指标调试HTTP应用程序

使用请求跟踪调试gRPC应用程序

针对Linkerd调试容器/边车：

kubectl -n get deploy/ -o yaml \

| linkerd inject -- enable-debug-sidecar - \

| kubectl apply -f -

左右滑动查看完整代码

调试Consul

Consul调试命令在Consul中极其简单。使用-capture定义您要分析的内容，并为间隔、持续时间、API、Go pprof 包等添加参数。

consul debug -capture agent -capture host -capture logs -capture metrics -capture members -capture pprof -interval=30s -duration=2m -httpaddr=126.0.0.1:8500

左右滑动查看完整代码

NGINX入站控制器

NGINX之所以值得关注，是由于它很容易结合使用两个单独的工具：NGINX入站控制器和NGINX服务网格。本节着眼于入站控制器。为了解NGINX如何定位这两个工具，其架构图大有帮助：

图1. NGINX架构图（入站控制器vs服务网格）

（来源：NGINX 文档）

您可以在这里介绍两种类型的日志：用于NGINX入站控制器本身，及/或更强大的整体NGINX日志。

使用NGINX入站日志进行调试

您可以通过将–v=5添加到Kubernetes部署的-args部分，将日志级别更改为debug。注意，NGINX部署必须使用--with-debug来构建，以便稍后获得调试日志。

kubectl edit deployment nginx-ingress-controller

spec:

containers:

- args:

- /nginx-ingress-controller

- --v=5

左右滑动查看完整代码

使用常规NGINX错误日志进行调试

配置NGINX日志时，您必须设置错误日志，这对于调试来说最重要。

但在此之前，您需要确保先用调试选项来编译NGINX（如果使用开源版）。虽然感觉没有必要，但目前情况就是这样，因为NGINX试图管理如何致力于存储日志数据。当然，默认情况下该选项可能完全关闭。

先下载NGINX的开源版，然后开始编译过程。

nginx -V 2>&1 | grep arguments

添加--with-debug参数

./configure --with-debug

编译：

sudo make

安装：

sudo make install

重新启动。

现在是第2阶段。仔细检查安装是否有-with -debug：

nginx -V 2>&1 | grep -- '--with-debug'

打开NGINX配置文件：

sudo vi /etc/nginx/nginx.conf

设置debug参数：

error_log /var/ log/nginx/error.log debug；

NGINX文档中有更多的选项。最后补充一点，还可以使用Syslog作为替代方案，这需要syslog:前缀，然后指定一台服务器（通过IP、UNIX套接字或域来指定）。

error_log syslog:server=130.78.244.101 debug;

access_log syslog:server=130.78.244.102 severity=debug;

左右滑动查看完整代码

调试Traefik（入站控制器）

Traefik Kubernetes Ingress控制器是另一种入站控制器。它管理Kubernetes集群服务，通过支持入站规范来管理对集群服务的访问。别将它与该公司的其他工具：Traefik Mesh和Traefik Gateway混为一谈。

与NGINX一样，Traefik Ingress日志和常规的Traefik日志及调试可以同时设置，也可以单独设置。

Traefik调试日志

您可以配置调试级别的Traefik日志，或通过Traefix API调试进行调试。两者都可以通过以下三种方式之一完成：通过Traefik CLI、.yaml配置文件或.toml配置文件。

日志方面，这是一个快速的三步过程：1. 设置filepath。2. 设置format（json或text）。3. 设置level。该示例演示了如何在Traefik CLI中执行此操作，但您也可以使用YAML或TOML配置文件。

--log.filePath=/path/to/traefik.log

--log.format=json

--log.level=DEBUG

debug是Traefik中的六个日志级别之一，但默认为ERROR（其他级别为PANIC、FATAL、WARN和INFO）。

Traefix API调试

在CLI中，设置 API：

--api= true

然后，您将会有针对Kubernetes及其他容器编排器或基础架构管理器（Docker Swarm和Docker等）的不同配置选项。不妨演示一个基于Traefik文档的Kubernetes CRD示例（在 YAML 中）：

apiVersion: traefik.containo.us/v1alpha1

kind: IngressRoute

metadata:

name: traefik-dashboard

spec:

routes:

- match: Host(`traefik.progress-regress-we-all-scream-4-ingress.com`) #this is clearly an example please do not visit this url and take no responsibility if it is real and unsafe

kind: Rule

services:

- name: api@internal

kind: TraefikService

middlewares:

- name: auth

---

apiVersion: traefik.containo.us/v1alpha1

kind: Middleware

metadata:

name: auth

spec:

basicAuth:

secret: someFancyShmancySecretiveIngressiveSecretNameShorterThanThis

左右滑动查看完整代码

然后，将其设置为在CLI中调试：

--api.debug= true

调试用于管理基础架构的Kubernetes工具

包管理器、基础架构即代码、配置管理器、自动化引擎等，许多彼此竞争的工具对相同的任务采用不同的方法，有时不是直接竞争，而是互为补充。

图2. 比较各种Kubernetes自动化、包和配置工具的非详尽的维恩图

调试Helm

Helm已成为很多人事实上的Kubernetes包管理器。它使用名为Helm Charts的面向Kubernetes部署的复杂模板。创建模板或构建用于部署的chart本身就是一个过程。有几种方法可以调试Helm模板。

--debug 标志

先检查您已经安装了哪些模板：

helm get manifest

然后让服务器显示模板，并返回清单文件：

helm install --dry-run --debug

或者：

helm template –debug

您也可以将–debug标志与大多数其他命令一起使用。无论您在做什么，它都会提供更详细的日志响应。您可以将这些日志委托给特定文件，如下所示：

helm test-f -debug > debuglogs.yaml

调试Terraform

Terraform不是为Kubernetes原生设计的，但它已成为首选。Terraform使用名为provider的支持包系统，构建了自己的Kubernetes provider。它使用HashiCorp 配置语言（HCL）来部署和管理Kubernetes资源、集群和API等。

或者，您可能更喜欢通过像hashcorp/helm这样的provider来工作，其功能比普通的Kubernetes选项更强大。您可以将Terraform日志用于多个日志级别之一，包括调试。还有用于调试Terraform provider或插件集成的特定策略。

Terraform调试日志

可以使用TF_LOG或TF_LOG_CORE记录Terraform本身，或者使用TF_LOG_PROVIDER记录Terraform和所有provider。您可以使用TF_LOG_PROVIDER_将日志设置扩展到只有一个特定的provider。

TF_LOG_PROVIDER=DEBUG

您还可以使用stderr用于日志，但无法在Terraform中使用stdout，因为它已经是专用通道。

您可以使用原生tflog包用于结构化日志，然后设置日志级别。根据您使用的是框架还是SDK Terraform插件，可以设置创建调试日志的上下文。考虑Terraform文档中的以下示例：

apiContext := tflog.SetField(ctx, "url", "https://www.example.com/my/endpoint")

tflog.Debug(ctx, "Calling database")

tflog.Debug(apiContext, "Calling API")

左右滑动查看完整代码

调试Kustomize

您可能已从拼写中猜到这是Kubernetes原生的。Kustomize是一个配置管理器，名字来源于定制配置文件。它不像Helm那样依赖模板，而是更喜欢严格使用YAML文件，甚至使用YAML文件来配置其他YAML文件。

现在，对于任何想要不依赖kubectl及其他元素来调试Kustomize的人来说，它更加复杂。不可能找到任何关于日志、跟踪，尤其是Kustomize本身调试方面的文档。

您可以在应用程序内的deployment.yml文件中将log_level用作调试级别。

env:

- name: LOG_LEVEL

value: "DEBUG"

之后，您将添加kustomization.yml文件，删除原始资源，然后重新部署应用程序。

调试Ansible

您必须启用调试设置，默认情况下它是关闭的。接下来，您可以使用debugger关键字，如Ansible文档中的该示例所示：

- name: Execute a command

ansible.builtin.command: "false"

debugger: on_failed

在 [defaults]部分中的ansible.cfg文件中全局启用它：

[defaults]

enable_task_debugger = True enable_task_debugger = True

调试Pulumi

Pulumi是后起之秀，主要是一种IaC工具。其工作原理是，将Kubernetes API公开为SDK来部署和管理IaC。Pulumi试图兼容生态系统中已经广泛使用的工具，因此它使用TF_LOG及其规则，就像在Terraform中一样。

Pulumi也有原生的日志配置，可以用常规的编程语言而不是CLI/领域特定的语言来操作。

此外，您还可以实现Pulumi Debug API。Pulumi的文档使用这个多选样式示例，参数中列出了不同的选项：

debug(msg: string, resource?: resourceTypes.Resource, streamId?:

undefined | number, ephemeral?: undefined | false| true): Promise

左右滑动查看完整代码

调试Kubernetes工具如同探险

每个工具都有不止一种方法来调试其服务和实现。一些工具有不同的方法来调试日志，另一些工具包括跟踪收集这一选项。开发者优先的可观测性要求您找到提供最清晰答案和最简单设置的选项。一些彼此竞争的工具也有可能在同一个Kubernetes堆栈中协作。但愿本文让您了解现有的工具以及您希望使用哪些工具用于Kubernetes调试。

原文链接：

https://www.cncf.io/blog/2022/09/15/10-critical-kubernetes-tools-and-how-to-debug-them/

结识技术大咖，提升IT技能

畅谈开发梦想，拓展人脉资源

参与话题讨论，赢取互动好礼

● React和Next.js已死，真的要被取代了？

● “天价”头显首发！Meta是赢了还是拼了？

● 没有谁能撼动C语言

由于公众号平台改变了推送规则，如果你想多看到我们的文章，记得点一下在看和星标哦~返回搜狐，查看更多